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DETAILED ACTION 

Response to Amendment 

This office action is responsive to the amendment filed on 1 1/30/2009. 
Claims 1-26 are pending in the Application. 

Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, mure than one \ ear prior to the date of application for patent in the United States. 

2. Claims 1-26 are rejected under 35 U.S.C. 102(b) as being anticipated by Hamiti et al (US 
6751209 Bl). 

Regarding claims 1, 12 and 13 , Hamiti discloses a method and a system to process the method of 
radio transmission of real-time IP packets using header compression, comprising: 

header-compressing a number of RTP packets, (fig. 1 : for each RTP packet 1 1 shown 
header compression is carried out) , to obtain header-compressed RTP packets having a plurality 
of different header compression lengths, (packet 16 with a plurality of different header 
compression lengths), wherein a single compressed header corresponds to a single RTP payload 
in each of the header-compressed RTP packets, (shown in the figure, element 16 each of the 
containing separate header corresponds to an RTP payload: this corresponds to different 
compression values, col. 8 lines 41-42), 
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pre-configuring header compression lengths and length types required by the system, 
(fig. 5, note the compressed RTP header: col. 7 lines 1-6: field 51 indicates the type T; 
correspondingly field 53 indicates the length), and 

PDU-size adapting the plurality of different header compression lengths of the header- 
compressed RTP packets, so as to comply with said lengths and length types required by the 
system, (col. 7 lines 1-6 indicates the lengths and length types for, if T=0, the last octet 56 is not 
included and the last six bits 53 of the first octet are set to zero, used for some other purpose, e.g. 
for CRC check, or used for an abbreviated time-stamp. If T=l the compressed header shall 
include the length octet and the bits 53 and the last octet 56 arc used to indicate the length of the 
RTP payload. Furthermore, fig. 5 field 56 represents the data block containing the compressed 
header: this corresponds a Packet Data Unit (PDU) contains an integral number of octets, a 
header part and a data part, col. 9 lines 50-54). 

Regarding claim 2 , Hamiti discloses marking a compressed header and an RTP payload, (The 
format of the compressed header follows the one presented in connection with fig. 5; thus as 
indicated, col. 7 lines 8-9: field 52 indicates the marker bit of the RTP header) and separating 
the compressed header from the RTP packet based on said marking before PDU-size adapting 
the header-compressed RTP packet, and then PDU-size adapting the separated compressed 
header, (as illustrated in fig. 3, considering the RTP, col. 5 lines 20-22, field 314 includes a 
marker bit that is optionally used to mark important events in the packet stream, for instance, the 
beginning of a speech burst, or a last packet in a video frame. If the marker bit 3 14 is used it 
needs to be transmitted in the compressed header). 
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Regarding claim 3 , Hamiti discloses after separating the compressed header from the RTP 
payload based on said marking, further dividing the RTP payload into blocks of different error 
sensitivities based on the RTP payload format information, then PDU-size adapting the 
separated compressed header, (col. 5 lines 20-22, field 314 includes a marker bit that is 
optionally used to mark important events in the packet stream, for instance, the beginning of a 
speech burst, or a last packet in a video frame). 

Regarding claims 4 and 15 , Hamiti discloses after dividing the RTP payload into blocks of 
different error sensitivities, combining the compressed header with at least one data blocks of 
the RTP payload, then PDU-size adapting the data blocks containing said compressed header, 
(col. 8 lines63-67 and col. 9 lines 1-14: a delay packet for a particular compression sequence 
(thus having a particular error sensitivity), may be combined with the payload for, a packet 
belonging to a compression sequence preceding the precedent compression sequence would not 
be regenerated correctly anymore and therefore such packets are preferentially managed already 
in the compressor. The flow chart of FIG. 7 presents an example of such a filtering algorithm 
that can be added to the invented method in the compressor side for managing situations with 
much delayed packets) 

Regarding claims 5 and 17 , Hamiti discloses applying a UEP mechanism to the separated 
compressed header and the RTP payload, or the separated compressed header and the data 
blocks of the RTP payload, or the data blocks containing the compressed header and the 
remaining RTP payload data blocks, (col. 5 lines 37-43: indicates unequal error protection 
mechanism that applies to RTP packet: this field does not have to be transmitted over the 
transmission link that has a strong error protection mechanism or means to detect transmission 
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errors (e.g. lower protocol layer checksums). Transmission of such information can be done 
using acknowledged mode or strong error protection). 

Regarding claim 6 , Hamiti discloses mapping the separated compressed header and the RTP 
payload, or the separated compressed header and the data blocks of the RTP payload, or the 
data blocks containing the compressed header and the remaining RTP payload data blocks to 
different RLC entities for transmission, (fig. 1 divided into an appropriate number of RLC blocks 
each containing a separate header) 

Regarding claims 7 and 18 , Hamiti discloses transmitting the compressed header and the RTP 
payload, or the separated compressed header and the data blocks of the RTP payload, or the 
data blocks containing the compressed header and the remaining RTP payload data blocks on 
the same transmission time interval, and configuring corresponding transport channels thereof 
as "coordinated dedicated transport channels, (In accordance with its program, the 
microprocessor uses the RF block 103 for transmitting and receiving messages on the radio path, 
(a dedicated channel)) 

Regarding claim 8 , Hamiti discloses receiving and extracting, at a receiving end, the compressed 
header and the RTP payload, or the separated compressed header and the data blocks of the 
RTP payload, or the data blocks containing the compressed header and the remaining RTP 
payload data blocks, from RLC entity SDU corresponding to the compressed header and the 
RTP payload, or the separated compressed header and the data blocks of the RTP payload, or 
the data blocks containing the compressed header and the remaining RTP payload data blocks, 
respectively, (fig. 9: the compressed packet is received at the decompressor (step 92), when 
changes are detected, a new SNDCP functionality will extract from the new header only the 
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changed no-change fields (step 96), update them to the stored state of compression (step 97), 
transmit said values to the SGSN (step 98) and update the values to the state of compression 
stored in the SGSN as well (step 98). 

Regarding claim 9 , Hamiti discloses combining the extracted compressed header and the RTP 
payload, or the separated compressed header and the data blocks of the RTP payload, or the 
data blocks containing the compressed header and the remaining RTP payload data blocks, into 
a complete RTP packet, (step 96 fig. 9, doing the extraction. Note fig. 1 that number of RLC 
blocks each containing a separate header) 

Regarding claim 10 , Hamiti discloses the lengths and length types required by the system depend 
on a tradeoff between transmission efficiency and TFCI decoding reliability, (fig. 5. note the 
TFCI is transferred across the air interface and allows the receiving layers to identify the current 
valid Transport Format Combination, thus as shown in fig. 3, col. 5 lines 12-16, field 315 
indicates the payload type and is constant for one type of data. Generally, the contributing source 
and synchronization source are constant throughout the transmission over the air interface, and 
therefore the field 318 will remain constant) 

Regarding claims 11 and 19 , Hamiti discloses the RLC entity is a TM mode RLC entity, (fig. 5). 
Regarding claim 14 , Hamiti discloses after separating the compressed header from the RTP 
payload, PDU-size adapting the compressed header, such that the plurality of different header 
compression lengths obtained when header- compressing the RTP packet are adapted to lengths 
and length types required by the system, and then making the PDU-size- adapted compressed 
header and the RTP payload to respectively form PDCP layer PDUs before mapping them into 
different RLC entities, (fig. 5 field 56 represents the data block containing the compressed 
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header: this corresponds a Packet Data Unit (PDU) contains an integral number of octets, a 
header part and a data part, col. 9 lines 50-54). 

Regarding claim 16 , Hamiti discloses combining the separated compressed header with at least 
one data blocks of the RTP payload, and PDU-size adapting the data blocks containing said 
compressed header, (fig. 5 field 56 represents the data block containing the compressed header: 
this corresponds a Packet Data Unit (PDU) contains an integral number of octets, a header part 
and a data part, col. 9 lines 50-54). 

Regarding claim 20 , Hamiti discloses a method of receiving real-time IP packets using header 
compression, wherein a compressed header of the header-compressed packet, (shown in the 
figure, element 16 each of the containing separate header corresponds to an RTP payload: this 
corresponds to different compression values, col. 8 lines 41-42), 

is separated from an RTP payload thereof at the transmitting end to form different 
PDCP layer PDUs that are transmitted on different RLC entities, and wherein a single 
compressed header corresponds to a single RTP payload in each of the header-compressed RTP 
packets, said method comprising: 

receiving and extracting the compressed header and the RTP payload from SDUs of the 
RLC entities, (fig. 9: the compressed packet is received at the decompressor (step 92), when 
changes are detected, a new SNDCP functionality will extract from the new header only the 
changed no-change fields (step 96), update them to the stored state of compression (step 97), 
transmit said values to the SGSN (step 98) and update the values to the state of compression 
stored in the SGSN as well (step 98), and 
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combining the extracted compressed header with the RTP payload, (col. 8 lines63-67 and 
col. 9 lines 1-14: a delay packet for a particular compression sequence (thus having a particular 
error sensitivity), may be combined with the payload for, a packet belonging to a compression 
sequence preceding the precedent compression sequence would not be regenerated correctly 
anymore and therefore such packets are preferentially managed already in the compressor. The 
flow chart of FIG. 7 presents an example of such a filtering algorithm that can be added to the 
invented method in the compressor side for managing situations with much delayed packets) 
Regarding claim 21 , Hamiti discloses a system of transmitting a real-time IP packet using header 
compression, comprising: 

a header compression unit to header-compress RTP packets and mark a compressed 
header and an RTP payload, (The format of the compressed header follows the one presented in 
connection with fig. 5; thus as indicated, col. 7 lines 8-9: field 52 indicates the marker bit of the 
RTP header), wherein a single compressed header corresponds to a single RTP payload in each 
of the header-compressed RTP packets, (shown in the figure, element 16 each of the containing 
separate header corresponds to an RTP payload: this corresponds to different compression 
values, col. 8 lines 41-42), 

a radio link adaptation unit to separate the compressed header from the RTP payload 
based on said marking, to respectively form PDCP layer PDUs before mapping the respective 
PDCP layer PDUs to different RLC entities, and a transmitter to transmit the separated 
compressed header and RTP payload, (fig. 3, considering the RTP, col. 5 lines 20-22, field 314 
includes a marker bit that is optionally used to mark important events in the packet stream, for 
instance, the beginning of a speech burst, or a last packet in a video frame. If the marker bit 3 14 
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is used it needs to be transmitted in the compressed header; furthermore, col. 4 lines 58-64, the 
access network SNDC function provides to the network layer a service for transferring a 
minimum amount of data between the SGSN and MS , (transmitters) through different 
compression techniques. 

Regarding claim 22 , Hamiti discloses a system of receiving a real-time IP packet using header 
compression, (fig. 10 and col. 12 lines 33-55: a mobile terminal of a mobile communication 
equipment), wherein a compressed header of the header-compressed packet is separated from an 
RTP payload thereof at the transmitting end to form different PDCP layer PDUs that are 
transmitted on different RLC entities, wherein a single compressed header corresponds to a 
single RTP payload in each of the header-compressed RTP packets, (shown in the figure, 
element 16 each of the containing separate header corresponds to an RTP payload: this 
corresponds to different compression values, col. 8 lines 41-42), said system comprising: 

receiving and extracting unit for to receive and extract the compressed header and the 
RTP payload from SDUs of the RLC entities, (fig. 9: the compressed packet is received at the 
decompressor (step 92), when changes are detected, a new SNDCP functionality will extract 
from the new header only the changed no-change fields (step 96), update them to the stored state 
of compression (step 97), transmit said values to the SGSN (step 98) and update the values to the 
state of compression stored in the SGSN as well (step 98), and 

radio link adaptation unit for combining the extracted compressed header with the RTP 
payload, (col. 12 lines 33-55:the microprocessor uses the RF block 103 for transmitting and 
receiving messages on the radio path.) 
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Regarding claim 23 , Hamiti discloses an RTCP packet scheduling method, comprising: 
monitoring whether or not the bandwidth requirement of the RTP packet exceeds a 
predetermined value, (col. 7 lines 31-65), if the bandwidth requirement of the RTP packet 
exceeds the predetermined value and there is an RTCP packet to be transmitted, (col. 7 lines 31- 
65), buffering the RTCP packet, (col. 4 lines 64-66, a number of the header data fields that 
remain constant during the data transfer being stored in the decompressor), and continuously 
monitoring the bandwidth requirement of the RTP packet, and transmitting the RTCP packet 
when the bandwidth requirement is lower than the predetermined value, (col. 9 lines 15-37: no 
packet transmitted due to delay conditions, the packet is deemed useless). 
Regarding claim 24 , Hamiti discloses the bandwidth requirement being lower than the 
predetermined value comprises the case where the compression rate of the RTP packet is so high 
that the bandwidth requirement is lower than the predetermined value, (col. 7 lines 66-67 and 
col.8 lines 1-30). 

Regarding claim 25 , Hamiti discloses the bandwidth requirement being lower than the 
predetermined value comprises the case where no RTP packet is transmitted, (col. 9 lines 15-37: 
no packet transmitted due to delay conditions, the packet is deemed useless) 
Regarding claim 26 , Hamiti discloses an RTCP packet scheduling system, comprising: 
bandwidth monitoring means for monitoring whether or not the bandwidth requirement of the 
RTP packet exceeds a predetermined value, (col. 7 lines 31-65), judging means for judging, 
whether the bandwidth requirement of the RTP packet exceeds the predetermined value and 
there is an RTCP packet to be transmitted, (col. 7 lines 31-65), buffering means for buffering the 
RTCP packet, in response to the result of the judging means that the bandwidth requirement of 
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the RTP packet exceeds the predetermined value, (col. 4 lines 64-66, a number of the header data 
fields that remain constant during the data transfer being stored in the decompressor); and 
transmitting means for transmitting the RTCP packet, in response to the result of the judging 
means that the bandwidth requirement of the RTP packet does not exceed the predetermined 
value, (col. 9 lines 15-37: no packet transmitted due to delay conditions, the packet is deemed 
useless). 

Response to Arguments 

With regards to clams land 12 

Applicant argues that Hamiti does not disclose "pre-configuring header compression lengths and 
length types required by the system" as recited in claims 1 and 12. 
Examiner disagrees and submits that Applicant appears to argue limitations not claimed: 
"the header size of the ROHC header- compressed packet from the upper layer is 
changeable in a wide range, thus a huge TFS must be employed to cover all the possible packet 
header sizes, which reduces the reliability of TFC1 decoding and complicates the physical layer 
processing" and 

"adapts the header-compressed packet or the compressed header or the data blocks 
containing the compressed header to several pre-configured size-fixed length ". 

Instead the claimed language requires pre-configuring header compression lengths and 
length types disclosed in fig. 5: length types conveyed in field 51 represented by T=0, and T=l; 
there is also disclosed lengths of compressed header, for the header fields are compressed into 
(different) abbreviated fields, each of which has length chosen during the compression sequence, 
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col. 6 lines 53-67 and col. 7 lines 1-7. Therefore, Examiner submits that Hamiti discloses the 
claimed limitations. 

With regards to "PDU-size adapting the plurality of different header compression lengths of the 
header-compressed RTP packets ", Applicant also argues that Hamiti fails to teach 

"the compressed header- packets are adapted to different sizes (i.e., lengths) as required 
by the system, so as to facilitate physical layer processing". 

Examiner disagrees and submits that, col. 6 lines 53-67, the header fields compressed into 
abbreviated fields (obtained during the compression sequence), have different lengths chosen to 
provide transmission of the information; therefore, the compressed header packets are adapted to 
various lengths. 

With regards to claims 13 and 21 

Applicant argues that Hamiti does not disclose "marking a compressed header and an RTP 
payload". 

Examiner disagrees and submits that, as required by the claims, field 52 (fig. 5) indicates the 
marker bit of the compressed RTP header, col. 7 lines 9-11. Furthermore, field 314 (fig. 3) 
includes the marker bit of the RTP payload: col. 5 lines 18-22. Therefore, Examiner submits that 
Hamiti teaches the claimed limitations. 

Applicant further argues that Hamiti does not disclose "separating the compressed header from 
the RTP payload based on said marking, to respectively form PDCP layer PDUs before mapping 
them to different RLC entities. 
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Examiner disagrees and submits that, in the compressed RTP header shown in figure 5, including 
the marker 52, the compressed header shall include the length octet and the bits 53 and the last 
octet 56 are used to indicate the length of the RTP payload. 
With regards to claims 20 and 22 

As required by the claimed limitations, Examiner submits that fig. 1 still teach a compressed 
header of the header-compressed packet, (Real Time Protocol (RTP packet) 1 1 is put into a User 
Data Protocol (UDP) packet 12 and further to an Internet Protocol (IP) packet 13; fig. 5 is the 
structure of the compressed header), is separated from an R TP payload, (the compressed header 
shall include the length octet and the bits 53 and the last octet 56 are used to indicate the length 
of the RTP payload), thereof at the transmitting end to form different PDCP layer PDUs that are 
transmitted on different RLC entities, (the Packet 13 is further encapsulated using Sub-Network 
Dependent Convergence Protocol (SNDCP) 14 and Logical Link Control protocol (LLC) into an 
LLC block 15, which is divided into an appropriate number of RCL blocks each containing a 
separate header: col. 4 lines 24-31). 
With regards to claims 23 and 26 

Applicant furthermore argues that Hamiti does not disclose "monitoring whether or not the 
bandwidth requirement of the RTP packet exceeds a predetermined value" and "if the bandwidth 
requirement of the RTP packet exceeds the predetermined value and there is an RTCP packet to 
be transmitted, buffering the RTCP packet". 

Examiner erroneously cited col. 7 lines 31-65 instead of col. 4 lines 31-65. However examiner 
maintains that Hamiti teaches monitoring the bandwidth requirement, because as described block 
15, which is divided into an appropriate number of RCL blocks the bandwidth utilization around 
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33% when a G723.1 encoder is used a compressed value for a header data identifies the data 
packet in a compression sequence; A number of the header data fields that remain constant 
during the data transfer are stored (or buffered) in the decompressor. 

Conclusion 

3. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to EMMANUEL MAGLO whose telephone number is (571)270- 
1854. The examiner can normally be reached on Monday - Thursday 7:00 - 4:30 and every other 
Friday 7:00 -3:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Trost can be reached on (571)272-7872. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/William Trost/ 

Supervisory Patent Examiner, Art Unit 
2472 

Emmanuel Maglo 
Patent Examiner 
March 16, 2010 



